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(57) ABSTRACT 

The element management system ("EMS") of the present 
invention addresses the need for effective and efficient 
management of heterogeneous telecommunications net- 
works that include network elements of different types, such 
as radios and fiber optic devices, made by different manu- 
facturers. This EMS provides a core set of element- 
independent network management messages that support 
basic network management functions, such as fault and 
performance monitoring and configuration management. 
Element-independent messages to an individual network 
element are mapped to an element-dependent message for 
that network element; messages from indiviidual network 
elements are correspondingly mapped into the core set of 
element- independent messages. Management applications 
and user interfaces in the EMS thus send and receive 
network management information using the core set of 
messages, in the common protocol of those messages. The 
EMS of the present invention thus supports rapid and 
low-cost integration of additional network elements of dif- 
ferent types and different manufacturers, additional manage- 
ment functionality and additional and modified telecommu- 
nications services. The present invention also provides a 
method for developing the core set of element-independent 
network management messages for basic telecommunica- 
tions management functions. 
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ELEMENT MANAGEMENT SYSTEM FOR 
HETEROGENEOUS 
TELECOMMUNICATIONS NETWORK 

CROSS REFERENCE TO RELATED 
APPLICATIONS 

In connection with this application, priority is claimed to 
the following provisional applications: SYSTEM AND 
METHOD FOR NETWORK CONFIGURATION 
MANAGEMENT, U.S. Ser. No. 60/121,425, filed Feb. 23, 
1999, and SYSTEM AND METHOD FOR NETWORK 
MANAGEMENT, U.S. Ser. No. 60/121,429, filed Feb. 23, 
1999. 

FIELD OF THE INVENTION 

The present invention relates to element management 
systems for telecommunications networks. More 
particularly, the present invention relates to element man- 
agement systems designed to monitor, control and configure 
a number of diverse network elements, such as microwave 
radios and telecommunications multiplexers, regardless of 
the communications protocol, type of interface or manufac- 
turer of the individual network elements. 

BACKGROUND ART 

Driven by government deregulation of telecommunica- 
tions services and the rapid introduction of new telecom- 
munications networking technologies, the telecommunica- 
tions industry has experienced unprecedented growth and 
change in recent years. The increasing demand for distrib- 
uted computing systems and instant availability of online 
services and information has made access to reliable high- 
speed telecommunications networks essential to the daily 
activities of corporate enterprises and individuals alike. To 
meet the demand for the latest technology and additional 
capacity, literally hundreds of telecommunications vendors 
now compete with each other in the marketplace for tele- 
communications solutions, offering a large variety of ser- 
vices and technologies, some offered as propriety, some 
offered as "standard," and some offered as "quasi-standard." 

As competition among telecommunications vendors has 
grown, so has the size, complexity and heterogeneity of 
modern telecommunications networks. These complex het- 
erogeneous telecommunications networks, which may span 
thousands of miles of territory, can — and frequently 
do — contain thousands of different network elements of 
various types, made by different manufacturers, and using 
different communications protocols. 

Managing these large, complex and heterogeneous tele- 
communications networks presents substantial challenges. 
For each network element, a network manager needs to 
know whether the elements are operating properly and what 
are the nature and severity of any problems. For most 
networks, it is highly desirable to obtain this information at 
a network management facility without having to dispatch 
personnel to the physical location of the network element. 
Systems that provide this information from a network ele- 
ment to a network management center, usually by telecom- 
munications links, are known as element management sys- 
tems ("EMSs"). Once management information regarding a 
network element is transmitted to the network management 
center, the network manager can analyze the information 
and direct corrective or other appropriate action. Once again, 
it is desirable for at least certain actions — such as shutting 
down an overheating radio before it burns itself out, or 
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rerouting traffic away from a malfunctioning multiplexer — 
that the action be taken at the network element site as the 
result of a command transmitted from a remote network 
management center. Similarly, it is desirable, to the extent 

5 possible, to control and configure network elements 
remotely from the physical location of the individual ele- 
ments. EMSs are used for these purposes, as well. 

Network elements of different types, such as radios and 
multiplexers, typically require separate EMSs, even if they 

10 are manufactured by the same company. Historically, an 
EMS for a particular network element could only be 
obtained from the element's vendor, usually at a substantial 
price. If, for example, a telecommunications network con- 
tains four different models of digital radios, the network 
5 administrator typically has to purchase and support four 
different EMSs, even if all the radios are from the same 
manufacturer. Thus, managing a telecommunications net- 
work containing network elements of different types, differ- 
ent protocols and different manufacturers is almost always 

20 mostly. 

In addition, different manufacturers frequently use differ- 
ent protocols and commands for managing their network 
elements. Often, the same manufacturer uses different pro- 
tocols and commands for different types of equipment that 

^ it manufactures. Indeed, even when a manufacturer claims to 
use a "standard" protocol for managing network elements 
(such as Q3, TL-1 or SNMP), it is not uncommon for that 
manufacturer to implement that protocol differently from 
other manufacturers. Moreover, documentation for a specific 

30 EMS and a specific network element may be unavailable, 
incomplete, out-of-date or incorrect. Hardware and software 
have bugs and limitations which also must be addressed. 

As a consequence of these and other problems, the 
expertise required to program, manage and troubleshoot a 

35 particular EMS for a particular type of network element 
made by one manufacturer is ordinarily of limited use when 
it comes to programming, managing and troubleshooting a 
different EMS for a different type of network element or 
even the same type of network element made by a different 

40 manufacturer. Thus, people who become experts at support- 
ing particular EMSs and network elements ordinarily cannot 
efficiently apply those skills to supporting other EMSs or 
other types of network elements. 

It is therefore not uncommon for a single operator to 

45 maintain separate teams of experts for each type of network 
element in its telecommunications network. Network admin- 
istrators who have already invested substantial sums of 
money in purchasing separate EMS systems for a variety of 
network elements, potentially made by different 

50 manufacturers, may also have to invest substantial sums of 
money and resources to develop and maintain the expertise 
required to support each type of network element made by 
each manufacturer. 

Network administrators trying to reduce the costs asso- 

55 ciated with employing separate teams of expert program- 
mers for each type of network element have attempted to 
purchase and use commercial off-the-shelf telecommunica- 
tions network management solutions to manage their net- 
work elements. These management solutions, however, can 

60 be extremely expensive, frequently support only certain 
network elements, and can require extensive system inte- 
gration and customization efforts. Consequently, a network 
administrator using a commercial off-the-shelf network 
management application often still has to purchase separate 

65 commercial off-the-shelf applications for each type of net- 
work element, or for each manufacturer of network elements 
used in the telecommunications network. 
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Moreover, most commercial off-the-shelf network man- 
agement solutions are geared towards the "legacy" archi- 
tectures of older telecommunications network management 
solutions. These legacy-based solutions frequently do not 
support the more recent protocols, such as CORBA and Q3, 
or do not support a particular manufacturer's implementa- 
tion of the more recent protocols, without expensive modi- 
fications. Indeed, some legacy-based solutions may require 
the network administrator to change the methodology of 
managing the entire telecommunications network. 

In addition, due in large part to the problems discussed 
above, many commercial element management systems 
available today lack scalability. Each time an organization or 
network administrator wants to add a new type of network 
element to the telecommunications network, or to start using 
a new manufacturer, a new team of experts or a new network 
management application, or both, must also be added. This 
also usually means that the organization or network admin- 
istrator must be prepared to take on a large and expensive 
integration effort, adding further to the costs and complexity 
of upgrading the network. 

Another problem faced by telecommunications network 
administrators today is that commercial or third-party EMSs 
may not provide the level of flexibility required for certain 
telecommunications network applications. For example, if a 
telecommunication network requires new or custom user 
interfaces, new functionality or new reporting capabilities, 
many commercial EMSs lack the flexibility to deploy such 
new or customized applications easily and inexpensively. 

Accordingly, today's telecommunications network 
administrators are frequently captive to the type and manu- 
facturers of network elements utilized in their current net- 
work. Often, the manufacturer and type of network elements 
already present in the network effectively determine which 
type of network elements can be added to the network, or 
from which manufacturer new network elements can be 
obtained, what kind of expertise must be obtained to manage 
the new network elements and which brand of network 
management software can be used. Once deployed, net- 
works and their management solutions must be supported 
for many years if the organization has any hope of recouping 
the substantial initial investments required. This often leads 
telecommunications network managers to conclude that they 
have lost control over the growth and development of their 
own telecommunications networks. This lack of control 
severely restricts an organization's ability to expand or 
modify its network, integrate new technology and respond in 
a timely manner to their organizations telecommunications 
requirements. 

In an attempt to begin to address some of these problems, 
the International Telecommunications Union ("ITU") pro- 
mulgates a set of telecommunications specifications known 
as Telecommunications Management Network ("TMN") 
standards. The TMN standards defines relationships 
between basic network building blocks (i.e., different net- 
work elements, different network protocols and different 
network management applications) in terms of standard 
interfaces. 

The TMN standards defines five major functional areas 
for network management systems, based on key activities 
performed by network management personnel, including: 
Fault Management — including trouble management, cor- 
rective actions for service, fault reporting and recovery; 
Configuration Management — including resource provi- 
sioning (timely deployment of resources to satisfy 
expected service demands), service provisioning 
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(assigning services and features to end-users), and 
configuration of equipment and resources; 
Performance Management — including processes that 
insure the most efficient utilization of network 
resources and their ability to meet service demands, 
and collection, correlation, and analysis of data regard- 
ing the service performance of network resources; 
Security Management — including control of access to and 
protection of both the network and network manage- 
ment systems against intentional and accidental abuse, 
unauthorized access, and communications loss; and 
Accounting Management — including processes that 
maintain customer billing as well as resource inventory. 
The TMN architecture provides for a division of man- 
agement capabilities according to layers. Each layer pro- 
vides a set of the functional elements (that is, Fault, 
Performance, Configuration, Security, and Accounting 
Management). Not all functional elements are required at 
each layer. The TMN Layers (from bottom to top) are: 
Network Element Layer — This layer typically provides 

the interface for managing the NE itself. 
Element Management Layer — This layer provides capa- 
bilities provide for managing multiple network ele- 
ments usually of the same type or manufacturer. 
Typically, this layer emphasizes fault management, 
configuration management, performance management 
and security for the NEs. 
Network Management Layer — This layer provides net- 
work management for a full network, including circuit 
configuration, performance, and fault management, as 
well as provisioning of bandwidth. 
Service Management Layer — This layer provides for net- 
work management of the services provided by the 
network, such as inventory (accounting management) 
of bandwidth and services. 
Business Management Layer — This layer provides for 
network management of billing, service allocation, and 
other business aspects of the network. 
A wide variety of protocols (e.g., Q3, CORBA, SNMP 
and TL-1) is used as the communications media between 
TMN layers. The Q3 protocol is widely used in Europe and 
Asia as the network management protocol of choice for 
numerous network elements — especially transport 
networks, that is, networks that transfer information at very 
high speeds using fiber optic and digital microwave radio. 
Q3 has also seen a surge of activity in the United States, 
especially in Synchronous Optical Network ("SONET*) and 
Dense Wave Division Multiplexing ("DWDM") deploy- 
ments. Toolkits to build applications using Q3 are supplied 
by companies such as Vertel, DSET Corporation, HP, and 
Sun Microsystems. 

In the telecommunications network management industry, 
the Common Object Request Broker Architecture 
("CORBA") is increasingly being used for integration of 
telecommunications software applications and NEs. 
Essentially, CORBA is a specification for an object-oriented 
architecture for distributed applications, CORBA implemen- 
tations are provided by a number of companies, the most 
widely deployed is called Orbix™ from IONA Technolo- 
gies. 

SNMP, or Simple Network Management Protocol, is a 
simple protocol for managing TCP/IP (or Internet-based) 
computer networks. SNMP is widely deployed as a man- 
agement protocol for routers, bridges and other computer- 
network related devices. In recent years, SNMP has been 
extended as a management protocol for many telecommu- 
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nications network elements, most specifically, ATM work management message from a NE. This EMS also 

(Asynchronous Transfer Mode) switches and routers. The includes means for mapping the upstream element* 

SNMP protocol is in the public domain, consequently, there dependent network management message into a upstream 

are numerous deployments and implementations. element-independent network management message 

TL-1 is by far the most widely used protocol in telecom- 5 selected from a core set of upstream element-independent 
munications management. Most of today's transport net- network management messages, and into a common 
work elements deploy TL-1 as the management protocol. element-independent message protocol. The EMS also 
Although there is some standardization to TL-1, most ven- j^des means for transmitting the upstream element- 
dors implement either a subset or superset of the TL-1 mde p e ndent network management message to a software 
comman . , , L1 10 application. As used in this specification and the appended 

Accordingly, there is a need for fleable and scalable daim ^ temj ,< meaQS , lo £ cal ^^jon 

element management systems for telecommumcataons net- h from a ^ regardle5S of me actual pbyska i 

works that can monitor and manage very large, heteroge- ^ lementation or embodiment, 

neous telecommunications networks and support rapid, low- ¥ , A . _ wo . , 

~t a *,r~^ In a preferred embodiment, the EMS in accordance with 

cost integration of new and different network element types „ ^ , * . r 

. . • . r 4 1 j ■ . c r*. 15 the present mvention optionally mcludes means tor receiv- 

having a vanety of protocols and a variety of manufacturers. . p ,. j , F j _. * 1 

0 J mg an unsohcited element-dependent network management 

SUMMARY OF THE INVENTION message, such as an alarm, from a NE, means for mapping 

An objective of the present invention is to provide a me unsolicited element -dependent network management 

telecommunications network element management system message into an element-independent network management 

("EMS") for controlling a plurality of diverse network 20 message identifying the NE and the nature and priority of the 

elements, regardless of the type, protocol or manufacturer of unsolicited element-dependent network management 

the network elements ("NEs")- message, and means for transmitting the element- 

A further objective of the present invention is to provide independent network management message to a software 

an EMS utilizing a core message set that all NEs in the application. 

network can support, thereby reducing redundancy and 25 In a preferred embodiment, the EMS in accordance with 

minimizing the effort and expense required to integrate new the present invention optionally provides support for NEs of 

and diverse NEs. more than one type, or more than one manufacturer, or both. 

Another objective of the present invention is to provide an In a preferred embodiment of an EMS according to the 
EMS sufficiently flexible to support network management present invention, the core set of downstream element- 
functions common to diverse NEs. independent network management messages comprises a 

Another objective of the present invention is to provide a reduced number of downstream network management mes- 

highly-scalable EMS, capable of supporting a large number sage supporting basic telecommunications network manage- 

of NEs. ment functionality. In a preferred embodiment, basic net- 

A further objective of the present invention is to provide 35 work functionality comprises core network management 

an EMS having a mechanism for incorporating diverse functions common to a broad array of equipment types and 

network management interfaces, thereby making the appli- core network management functions specific to particular 

cations and services of the EMS independent of the protocol equipment types. In today's environment, a preferred 

used by individual NEs in the telecommunications network. embodiment of the present invention would support equip- 

The present invention, as broadly described herein, pro- 40 ment types such as microwave radios, add/drop 

vides a method for developing a core set of messages for an multiplexers, terminal multiplexers and fiber regenerators. 

EMS for a telecommunications network, comprising the Additional objects and advantages of the invention are set 

steps of: reviewing telecommunications network manage- forth in part in the description that follows, and in part are 

ment functions for each of a plurality of NEs; selecting the obvious from the description, or may be learned by practice 

basic telecommunications network management functions; 45 of the invention. The objects and advantages of the mvention 

and creating an element-independent telecommunications may also be realized and attained by means of the instru- 

network management message, in a common telecommuni- mentalities and combinations particularly set out in the 

cations management message protocol, for each selected appended claims. 

telecommunications management function. BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention, as broadly described herein, also 50 m . , . , j . 
provides an EMS for a telecommunications network com- T° c accompanying drawings , which are incorporated in 
prising means for receiving, from a software application, a «d constitute part of the specification, illustrate preferred 
downstream element-independent network management embodiments of the invention, and together with the 
message selected from a core set of downstream element- description, serve to explain the principles of the invention, 
independent network management messages, for transmis- 55 RG - 1 provides flowchart of a method of the present 
sion to a NE. The EMS further includes means for mapping mvention for developing a core set of messages for an 
the downstream element-independent network management element management system for a telecommunications net- 
message into a downstream element-dependent network work. 

management message, and into an element-dependent FIG. 2 depicts an embodiment of an EMS according to the 

protocol, for the NE. The EMS also includes means for 6 o present invention. 

transmitting the downstream element-dependent network FIG. 3 depicts, in a preferred embodiment of an EMS 

management message to the NE. As used in this specifica- according to the present invention, the logical relationship 

tion and the appended claims, the term "downstream" means between network management messages in a core set of 

a logical transmission path towards a NE, regardless of the network management messages. 

actual physical implementation or embodiment 65 FIG. 4 depicts the upstream and downstream flows of 

The EMS of the present invention may further comprise network management messages in a preferred embodiment 

means for receiving an upstream element-dependent net- of an EMS according to the present invention. 
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FIG. 5 depicts an alternate preferred embodiment of an to be supported. In a preferred embodiment, consideration is 

EMS according to the present invention. also given to the importance of the goal of keeping as small 

as practicable the number of messages to implement basic 

DETAILED DESCRIPTION OF THE network management functions. Achieving this goal is 

PREFERRED EMBODIMENTS s important to scalability of an EMS and to the ability quickly 

Reference will now be made in detail to the preferred and efficiently to add NEs of different types and manufac- 

embodiments of the invention, examples of which are illus- At me ^ ,f lhe selected 561 of basic man - 

tratcd in the accompanying drawings. Notably, the present a gement factions is too small, then important functions 

invention may be implemented using software, hardware or may te excluded or NEs of certain types or manufacturers 

any combination thereof, as would be apparent to those of 10 may not te adequately supported. It is therefore contem- 

ordinary skill in the art, and the figures and examples below P lated •>» 0016 ^ of netwo * management functions 

are not meant to limit the scope of the present invention or selected ^cording to the present invention may change in 

its embodiments or equivalents. response to changes in telecommunications requirements, 

. , , network implementation practices and industry consensus. 

A method of developing a core set of messages for an „, , . . f„ . „ ' , .„ ^ 

element management system according to the present inven- 15 Telecommunications NEs can usefully be classified 

tion wiU now be described in detail with reference to FIG. according to type. Various types of telecommunications 

1. That figure provides a process flowchart illustrating the ^ such 85 microwave radios and fiberoptic multiplexers, 

steps performed in developing a core set of messages for an ^m^l support and require distinct kinds of network 

element management system in accordance with the present „ n management functionality Certain network management 

invention, comprising the steps of (a) reviewing telecom- 20 ^ nctl0DS for multiplexers, for example are not appropriate 

munications network management functions for each of a for L microwave radios. For example, in a preferred 

plurality of telecommunications NEs; (b) selecting basic embodiment, where the NE is an add/drop multiplexer, pairs 

telecommunications network management functions; and (c) ° f optical interfaces may be cross-connected on command 

creating an element-independent telecommunications net- from the EMS to complete a circuit through the multiplexer, 

work management message, in a common telecommunica- 23 71,15 operation is not available-nor does it make sense— 

tions message protocol, for each selected telecommunica- mD the case where the NE is a microwave radio, 

tions management function. 0° me omer hand, certain network management functions 

In a preferred embodiment depicted in FIG. 1, the step of would be ^ewed by a person of ordinary skill in the art as 

reviewing telecommunications network management tunc- 30 common to ^ telecommunications NEs within a telecom- 

tions for each of a plurality of telecommunications NEs is munications network, regardless of the type of the NE. The 

performed at Review Network Management Functions step ne twork management function of setting the time on a 

101. For this step the functional specifications for each of a specified telecommunications NE, for example, should be 

plurality of telecommunications NEs may be obtained, for supported by all telecommunications NEs, regardless of 

example, by requesting them directly from the vendors, 35 whemer the element is a radio, a multiplexer or another type 

searching for them on the Internet, or by means generally °* device. 

known to those of ordinary skill in the art. m order to reduce redundancy in developing and using a 

Once the functional specifications of a network element core set of network management messages according to the 

are obtained, they are reviewed and audited for several present invention, m a preferred embodiment the basic 

purposes, including identification of the NEs network man- « 00,11111011 nctwork management functions are identified sepa- 

agement functions, such as retrieving the operating tempera- ratel y bom ^ basic network management functions for 

hire of the device, and identifying the specific network specific types of NEs. It is then preferable, according to a 

management protocols, such as Q3, TL-1 or SNMP, used by P refe rred embodiment of the present invention comprising a 

the NE. These specifications are also reviewed to ascertain network with radio and fiber optic devices, to subdivide the 

which network management functions are common to types 45 basic lype-specific notwwk management functions into 

of NEs made by several manufacturers, as well as different basic microwave radio network management functions and 

tvoes of NEs basic " ber °P tlc device network management functions. The 

» j ■ . j • t^.^ 1 • * j i_ j- • .1. . two classes of telecommunications NEs referenced herein, 

As depicted in FIG. 1, in a preferred embodiment the step ,« , . , , t .. ... 

• , . as well as the basic network management functions related 

of selecting basic telecommunications network management ... . . . , - _ , ... 

? , ..-,..„.„ .• . to these two classes, are mentioned by way of example only, 

functions is performed at Select Basic Functions step 102. so . c . ' ... / , : 

, r f. . . . . . .... Other types of telecommunications NEs having other basic 

The goal of this step is to develop, from the telecommuni- networ ^ manageraent ^Uods, as known to those of ordi- 

cations management functions reviewed at Review Network ^ ^ ^ , c i CCO mmu- 

Management Functions step 101, a reduced or core set of . \. . ' J . . , , f • _ a 

& . , r > nications network and are envisioned to fall within the scope 

messages that encompasses no more and no less than the _ . . . r 

. t? . ,. . , , . of this invention, 

basic functionality required to manage a telecommunica- 55 . . 

tions network. Several considerations affect this selection In a Preferred embodiment of the present invention, the 

process. In a preferred embodiment, consideration is given basic common network management functions, for each NE, 

to the commonality of a network management function mchjde ^ factions of: 

across different network element types and manufacturers. Setting a time clock for the NE. 

The more common a function, the more likely its inclusion 60 Retrieving performance data for a specified time period 

in a core set of basic functions. In a preferred embodiment, for the telecommunications NE. Such data would 

consideration is also given to industry-wide consensus as to include, for example, the total number of seconds in a 

which management functions are considered basic or nec- specified time period that the telecommunications NE 

essary or essential, or merely desirable. In a preferred was unavailable, the total number of seconds in a 

embodiment, consideration is also given to projections as to 65 specified time period that the telecommunications NE 

future types or features of NEs and the management func- sustained severe errors, the total number of framing 

tions they will need to support and by which they will need error sustained by the telecommunications NE in a 
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specified time period, and other performance data as retrieving the current time on a specified telecommuni- 

would be apparent to one of skill in the art. cations NE; 

Setting performance management threshold vahies for the resynchronizing the entire network; 

telecommunicadoiis NE. This function, for example, rcS ynchronizing the current alarm list for the telccommu- 

specifies which attributes to monitor on the telecom- s . ,■ kttT h 

munications NE and what kind of alarm will be gen- nicauons in^, ana 

erated if any of these monitored values falls outside the resyncbxonizing the performance management data for a 

specified threshold. This function could be used, for specified time period for a specified telecommunica- 

example, to generate a specific alarm when the number tions NE. 

of framing errors on the telecommunications NE 10 The basic microwave radio network management 
exceeds a certain value. functions, in accordance with a preferred embodiment, corn- 
Updating the external output control attributes on the prise the functions of invoking and releasing protection for 
telecommunications NE. For example, the state (e.g., the telecommunications NE, and requesting a manual exer- 
polarity) of an external output control may be changed from c ise on one protection unit, related to the regular channel on 
"normally ON" to "normally OFF." Another example would the telecommunications NE in order to insure that the 
be to set the "pulse" attribute to indicate that the external 1 protection (or redundant) channel can carry traffic, without 
output control is a "pulse" instead of a "latch." actually switching traffic to the protection channel. 

Sending a signal to the external output interface on the NE In a preferred embodiment, the basic fiber optic device 
for the purpose of controlling external equipment, such network management functions comprise the functions of 
as a generator. For example, by sending a pulse control, retrieving, entering, editing and removing a fiber optic 
the generator can be started. facility (hardware and software components used to provi- 
Updating the external input control attributes on the sion a communication path) and retrieving, performing and 
telecommunications NE. Such attributes include, by removing a cross-connection on the telecommunications 
way of example, the setting of the user label attribute NE. In a preferred embodiment depicted in FIG. 1, after 
to indicate the name of an assigned input device and 25 Select Basic Functions step 102, in the method of the present 
other attributes as would be apparent to one of skill in invention the step of creating an element-independent tele- 
the art. Such external input points are typically communications management message, in a common tele- 
assigned to external devices to be monitored by the communications network management protocol, for each 
EMS such as shelter doors, power capabilities, shelter selected telecommunications management function, is per- 
and equipment temperatures, smoke and fire detectors, 3Q formed in Create Element-Independent Message step 103. 
tower lights and other input devices. This step is begun in a preferred embodiment by defining a 
Retrieving operational status information of the telecom- structural definition and functional interface for the selected 
munications NE, such as whether the NE is "in service" function. The functional interface is characterized by creat- 
or "out of service." ing a name, syntax, parameter list and associated callback 
Retrieving, entering, editing and removing the telecom- 35 method for the selected function. 

munications NE from the EMS. For example, in a preferred embodiment, an element- 
Retrieving and updating protection status for the telecom- independent network management message for the function 
munications NE. Protection status for a telecommuni- of retrieving the current fist of standing alarms from a 
cations NE indicates whether the telecommunications specified network element is created as follows. Using 
NE has an active backup facility, such as a redundant <o CORBA IDL (Interfact Deflation Language), a structure (or 
channel, for use if the primary facility (or channel) data tv P e ) * defined for the s m P ut Parameter 
becomes unavailable to carry traffic. For example, a 

digital microwave may be configured as a "1+1," Typedef string NEName; 
meaning that there is one primary radio link between 

radio antennas and one backup link. If the primary link 45 This instruction creates a string data type, which can now be 

goes down for any reason, the radio will automatically used in subsequent function calls. Next a CORBA IDL 

switch to the backup radio link, using separate function is defined, as follows: 
antennas, separate receivers and separate transmitters. 

Processing the current standing alarms for the specified ^_ . K _ A1 m ^mx rt 4nM..MPw am . 

& . . fcT _ _ , , . , f , , Oneway void RctneveNEAlarms (in EMSCOMMON::NEName 

telecommunications NE. Such alarms would include, so neName); 
for example equipment, environmental, 

communications, facility, security, quality of service As would be apparent to one of skill in the art, the phrase 
and other standing alarms as would be apparent to one "Oneway void" in the above function indicates that no 
of skill in the art. immediate response to the message is expected. In other 
Some functionality provided with various telecommuni- 55 words, this is a "oneway" message. As suggested by its 
cations NEs may not considered essential to the satisfactory name, the function "RetrieveNEAlarms" directs the NE to 
operation of the telecommunications network and may provide the EMS with current status of any alarms activated 
therefore be excluded from the list of essential common in the NE. As also apparent to one of skill in the art, the word 
network management functions. In a preferred embodiment, "in" in the above function indicates that the parameter that 
for example, as long as the element management system has 60 follows ("neNamc w ) is an "input" parameter, as opposed to 
the capacity to set the current time on each NE, it is not "output" parameter. The input parameter "neName" is sup- 
essential to the management of the telecommunications plied to the CORBA implementation function in order to 
network to support the function of setting the current time identify the telecommunications network element from 
for the entire network as a whole, since sending a "set time" which the current list of alarms is to be extracted and the 
command to each NE would have the same effect. In a 65 descriptor "EMS COMMON" identifies a module contain- 
prefened embodiment, other non-essential network manage- ing the definitions for the data type "NEName" (in this case 
ment functions include, for example: a string). 



08/23/2004, EAST Version: 1.4.1 



US 6,260,062 Bl 



11 



12 



Thus, when the above-described "RetrieveNEAlarms" 
function is used ("called") in an application program, an 
element-independent network management message is cre- 
ated and seat to the telecommunications network element. 
The message is "element- independent" because it will oper- 
ate on any telecommunications network element in the 
network, regardless of the network element's type, protocol 
or manufacturer. When all of the standing alarms on the 
network element have been obtained, a "callback" function 
is activated, which will supply the application program with 
a list of standing alarms. 

The example message above has one input parameter, 
"neName," and no output parameters. Other messages may 
be created in accordance with the present invention, and 
other programming languages may be used, with or without 
incorporating multiple input and output parameters and 
associated callbacks, as would be evident to one of ordinary 
ski LI in the art. From the above example, it is also readily 
apparent to those of ordinary skill in the art how to create 
other element-independent network management message 
for specified network management functions in accordance 
with the present invention. 

In alternative preferred embodiments, basic network man- 
agement functions may be implemented by telecommunica- 
tions network element, by devices connected to telecommu- 
nications network elements, by other components, or by a 
combination of elements, devices and components in the 
network or the EMS as would be apparent to one of ordinary 
skill in the art. 

In a preferred embodiment, the basic network manage- 
ment functions identified in Select Basic Functions step 102 
arc implemented in Create Element-Independent Message 
step 103, using twenty-eight element-independent network 
messages: 

set __NETime — Sets the time for a specified NE. 

set__ThresholdData — Sets threshold values for perfor- 
mance management attributes for an NE. 

get_NE24HourPmData — Retrieves twenty -four hour 
performance attributes for a specified NE for specified 
dates and sends the response data upstream. 

get_NE15MinPmData — Retrieves fifteen-minute perfor- 
mance attributes for a specified connected NE and 
sends the response data upstream, 

get_CurrentNE15MinPmData — Retrieves current 
fifteen-minute performance attributes for a specified 
NE and sends the response data upstream. 

set„ExteraalOutputControI — Updates the external output 
control attributes for a specified NE and sends a 
response code upstream. 

Perform_extemalOutputControl — Sends a pulse or latch 
signal to a specified pin on the external output interface 
of a specified NE and sends a response code upstream. 

set_ExternalInputPoinl — Updates the external input con- 
trol attributes in a specified NE and sends a response 
code upstream. 

get_operationalState — Retrieves the current operational 
state for a specified NE. 

Get_Equipment — Retrieves a single equipment entity 
(e.g., a circuit board) for a specified NE. 

Get_MUXFacility — Retrieves a single fiber-optic device 
facility (e.g., signal or port) for a specified NE. 

Get_MUXCrossConnections — Retrieves existing cross 
connections for a specified fiber-optic NE. 

Enter_Equipment — Provides initial equipment attributes 
or characteristics for a specified NE. 



10 



15 



20 



25 



30 



35 



40 



45 



50 



55 



60 



65 



Edit_Equipment — Edits existing equipment attributes or 
characteristics for a specified NE. 

Remove_Equipment — Removes an existing equipment 
entity for a specified NE. 

Enter_MUX_Facility — provides an initial fiber-optic 
device facility for a single NE. 

Edit_ w MUX_Facility — Edits the attributes or character- 
istics of an existing fiber-optic device facility for a 
single NE. 

Remove_MUX_Facility — Removes an existing fiber- 
optic device facility for a single NE. 

Connect — Connects two optical or electrical termination 
points for a fiber-optic device in order to create a circuit 
through a specified NE at a specified rate, and sends a 
response code and the identifier of the circuit upstream. 

Disconnect — Disconnects an existing circuit for a speci- 
fied NE and sends a response code upstream. 

Get_AllProtectionGroups — Retrieves protection group 
objects (e.g., protection subsystems) for a specified NE. 

Get ProtectionUnits — Retrieves protection unit objects 

(e.g., redundant and normal channels) for a specified 
NE. 

Invoke_Protection — Requests that a NE switch from its 
regular channel or protection unit to a redundant or 
backup channel or protection unit and sends a response 
code upstream. 

ReleaseProtection — Requests that a NE switch back to its 
normal channel or protection unit form a redundant or 
backup channel or protection unit and sends a response 
code upstream. 

RadioInvokeExercise — Requests that a NE perform a 
switch from its regular channel or protection unit to a 
redundant or backup channel or protection unit without 
actually routing traffic onto the redundant channel or 
protection unit, and sends a response code upstream. 

RetrieveNEAlarms — Retrieves existing alarms for a 
specified NE. 

ClearAlarm — Clears a standing alarm within the EMS 
and for a specified NE. 

ProcessEVent — Passes unsolicited event and alarm infor- 
mation (Notificationlnfo) throughout the EMS. 

A core set of element-independent network management 
messages may readily be divided into downstream element- 
independent network management messages and upstream 
element-independent network management messages, as is 
readily apparent to one of skill in the art. 

FIG. 2 depicts a preferred embodiment of an element 
management system in accordance with the present 
invention, including (a) means for receiving, from a soft- 
ware application, a downstream element-independent net- 
work management message selected from a core set of 
downstream element-independent network management 
messages, for transmission to a telecommunications NE; (b) 
means for mapping the downstream element-independent 
network management message into a downstream element- 
dependent network management message, and into an 
element-dependent protocol, for the telecommunications 
NE; and (c) means for transmitting the downstream element- 
dependent network management message to the telecom- 
munications NE. 

With reference to the preferred embodiment shown in 
FIG. 2, the receiving means of an EMS system 202 accord- 
ing to the present invention is Upstream Agent 212. As 
depicted in FIG. 2, Upstream Agent 212 receives a down- 
stream element-independent network management message 
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from a Network Management Layer software application, tion with the transmission by Request Broker 211 of an 
depicted in FIG. 2 as NMS-EMS Interface 213, for trans- element-independent network management message, 
mission to a telecommunications network element, depicted "Connect," to Network Element 231 (a fiber-optic add/drop 
in FIG. 2 as Network Element 230. Other Network Elements multiplexer as depicted in FIG. 2). This message instructs 
231-239 are also depicted in FIG. 2. In a preferred 5 that multiplexer to establish a connection within the multi- 
embodiment, the downstream element-independent network P lexer t0 form a ckcuit from P oint A f° P oint B - ^ 
management message received by Upstream Agent 212 is element-independent message is transmitted to Adapter 

selected from a core set of downstream element-independent B1 ° ck ^ se ™S *f w °* E1 ^™ nl includes 

network management messages developed in accordance ^rmation sufficient for Network Element 231 to receive 

. lL ? , , , ... c r . rir- 1 « and execute the mstruction. Such information includes, for 

with the method described with reference to FIG. 1. 10 example? lhe identity of Nelwork Bement 231 according to 

Upstream Agent 212 provides an external interface, in a me ' edfic te i econ / munications netW0 rk, the identifiers of 

standardized protocol, such as Q3 or other protocol known me « from „ and « tQ „ poftSt md an identifier specifying the 

to one of skill in the art, between EMS 202 and NMS-EMS transmission rate. In the preferred embodiment depicted in 

Interface 207 and Network Management Layer applications pIG. 2, Adapter Block 221 receives the Connect message, 

and products, such as Other NMS Application 206 and Other 15 ^ using a combination of hardware and software as is 

NMS Application 208 in NMS Applications 201. Upstream known to one of skill in the art, selects an appropriate 

Agent 212 also receives messages to be forwarded to message for enabling Network Element 231 to execute the 

NMS-EMS Interface 207. In a preferred embodiment, instruction. In a preferred embodiment, this selection is 

Upstream Agent 212 may be implemented in hardware, accomplished using a table look-up or other methods known 

software, or a combination of both, as is known to persons 20 to one of skill in the art for mapping the element- 

of skill in the art. independent network management message to an appropri- 

In the preferred embodiment depicted in FIG. 2, the ate corresponding element-dependent message. Adapter 

means for mapping the downstream element-independent Block 221 then creates an element-dependent message, in 

network management message into a downstream element- the protocol utilized by the particular type and manufacture 

dependent network management message is Adapter Block 25 of network Element 231 (e.g., Q3), including information 

220. Adapter Blocks 221-229 perform similar functions. In sufficient to enable Network Element 231 to execute f the 

the preferred embodiment depicted in FIG. 2, Upstream Connect instruction to establish a connection to form a 

Agent 212 passes an element-independent downstream mes- circuit between point A and point B within Network Element 

sage to Request Broker 211, which in turn passes the 231. 

element-independent network management message to one 30 (In this example, at some later time Network Element 231 
of Adapter Blocks 220-229 serving the NE identified in the generates an element-dependent response to the Connect 
network management message. Each adapter block is suit- instruction, in order to inform EMS 202 that the connection 
ably equipped to receive (and transmit) network manage- has been formed, and providing an identifier for the con- 
ment messages. Request Broker 211 may be implemented nection. This response message is an element-dependent 
using hardware, software or a combination of both, as 35 upstream message. The mapping of element -dependent 
known to persons of skill in the art, and using techniques for upstream messages into element-independent network man- 
routing network management messages to adapter blocks agement messages, and their upstream transmission from 
serving specific NEs as known to persons of skill in the art. network elements, are described in detail below.) 

As depicted in FIG. 2, Adapter Blocks 220 through 229 In a preferred embodiment depicted in FIG. 2, the means 

map (or translate) the downstream element-independent 40 for transmitting the downstream element-dependent network 

message into an element-dependent network management management message to the telecommunications network 

message and an element-dependent protocol, such as TL-1, element are Adapter Blocks 220-229. This transmission is 

SNMP or Q3, for a specified NE. Network Element 230 accomplished using equipment and techniques as are known 

through 239 may comprise, for example, microwave radios, to those of skill in the art. 

and fiber optic devices such as digital multiplexers. In a 45 In another preferred embodiment (not depicted), the func- 

preferred embodiment depicted in FIG. 2, Adapter Block tions of Upstream Agent 212, Request Broker 211 and 

220 serves Network Element 230 which is for example a adapter Blocks 220 through 229, as described above, may be 

radio. Adapter Block 221 serves Network Element 231, implemented, without diverging from the scope of the 

which is for example a multiplexer, and so forth. This present invention, by various structures, as would be appar- 

service includes transmitting and receiving network man- 50 ent to those of ordinary skill in the art. Similarly, in another 

agement messages, using suitable hardware and software, to preferred embodiment (also not depicted) the functions of 

and from adapter blocks. Upstream Agent 212, Request Broker 211 and Adapter 

In a preferred embodiment, multiple units of the same Blocks 220 through 229, as described above, may also be 

type and manufacture of a network element may be served implemented by means of other separate structures or a 

by a single adapter block. For example, all NEC microwave 55 combination of structures, different from those depicted in 

radios in a network may be served by a single adapter block. FIG. 2. 

It is also possible that a single adapter block may serve As depicted in FIG. 2, an EMS of the present invention 
network elements of different types and different may include (a) means for receiving an upstream element- 
manufacturers, as would be apparent to one skilled in the art, dependent network management message from a telecom- 
without departing from the present invention. Request Bro- 60 munications network element; (b) means for mapping the 
ker 211 may thus route a single message to multiple adapter upstream element-dependent network management message 
blocks. For example, in the preferred embodiment depicted into a upstream element-independent network management 
in FIG. 2, to reset the time on an entire network, Request message selected from a core set of upstream element- 
Broker 211 would send a single element-independent mes- independent network management messages, and into a 
sage to all Adapter Blocks 220 through 229. 65 common element-independent message protocol; and (c) 
With reference to FIG. 2, in a preferred embodiment, means for transmitting the upstream element-independent 
another example of the mapping function occurs in connec- network management message to a software application. 
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In a preferred embodiment depicted in FIG. 2, the means stream element-independent network management mes- 
for receiving an upstream message from Network Element sages into corresponding downstream element-dependent 
230 is Adapter Block 220. Adapter Blocks 221-229 perform network management messages) may be similarly accom- 
similar functions with respect to Network Elements plished. In a preferred embodiment, a CORBAIDL compiler 
231-239, respectively. As depicted in FIG. 2, the receiving 5 and Object Request Broker implementation, available from 
means may be implemented using techniques and technolo- IONA Technologies (Orbix TO product) is used to facilitate 
gies as known to one of skill in the art. According to the the establishment of the correspondences between element- 
present invention, upstream element-dependent messages dependent and element-independent upstream network man- 
may be solicited (for example in response to a downstream agement messages, and between element-dependent and 
message) or unsolicited (for example in response to an alarm 10 element-independent downstream network management 
triggered by a NE, as known to one of skill in the art). Each messages. Other compilers and implementations may be 
Adapter Block 220-229 maps each received upstream used, as known to those of skill in the art. 
element-dependent network management message into an In a preferred embodiment, responses by the NEs to 
upstream element-independent network management mes- downstream messages (as distinguished from unsolicited 
sage. Again, these element-independent network manage- is upstream messages) which are mapped to element- 
ment messages are selected from a core of upstream independent messages by Adapter Blocks 220-229 are 
element-independent network management messages ere- routed to Request Broker 211, which then further routes the 
ated in accordance with the method of the present invention element-independent message (e.g., Connect_Response) as 
described with reference to FIGS. 1 and 2, above. Adapter a callback to the originating application. In a preferred 
Blocks 220 through 229 also translate the element- 20 embodiment, the message routing scheme of Adapter Blocks 
dependent message into a common element-independent 220-229 routes all unsolicited messages to Event Manager 
message protocol, as known to one of skill in the art. 210 and all Responses (to previous downs-stream requests) 

For example, with reference to FIG. 2, in a preferred to Request Broker 211. In such an embodiment, Adapter 

embodiment an unsolicited network element-dependent Blocks 220-229 simply note the type of messages received 

alarm message may be generated by Network Element 230. 25 to determine how to route any response element- 

The element-dependent alarm message is transmitted in the independent upstream message. 

protocol (e.g., Q3) used by the particular manufacturer for In the preferred embodiment depicted in FIG. 2, the 

the particular equipment type of Network Element 230. The means for transmitting the upstream element independent 

message would typically specify the alarm type (e.g., equip- network management message to a software application 

ment alarm, software alarm, environmental alarm, commu- 30 includes Request Broker 211 and Upstream Agent 212. As 

nications alarm) and the probable cause (e.g., power loss, depicted in FIG. 2, Request Broker 211 receives network 

software interruption, enclosure entry, signal loss). The management messages from Adapter Blocks 220-299, and 

element-dependent alarm message is received by Adapter routes those messages to Upstream Agent 212, which in turn 

Block 220 serving Network Element 230. In a preferred transmits them upstream to NMS-EMS Interface 213 in 

embodiment, a combination of computer hardware and 35 NMS Applications 201. Means, techniques and equipment 

software in Adapter Block 220, as known to one of skill in for transmitting messages to software applications are 

the art, parses the element-dependent alarm message, known to one of skill in the art. 

extracting the information to be transmitted to Event Man- As depicted in FIG. 2, an EMS of the present invention 

ager 2 10, including the identity of Network Element 220, the may include (a) means for processing fault management 

fact that the messages in an unsolicited alarm message, the 40 information; (b) means for logging all network notifications 

type of the alarm, and the probable cause. The combination and events into a database; (c) means for forwarding email 

of hardware and software in Adapter Block 220 then deter- from the software application; and (d) means for storing 

mines that element-independent network management mes- notifications and events. 

sage "ProcessEvent" is the appropriate network manage- In a preferred embodiment depicted in FIG. 2, means for 

ment message from the set of core network management 45 processing fault management information is Event Manager 

messages, for transmitting the alarm message information to 210, which is the central processing entity for the EMS, 

Event Manager 210. This determination is made using a responsible for managing all "standing alarms," as well as 

table look-up or other method, as is known to one of skill in providing synchronization between itself and an optional 

the art, for selecting the "ProcessEvent" message to send in fault management software application (not depicted). In a 

response to the received element -dependent alarm message. 50 preferred embodiment, all events that are generated within 

The combination of hardware and software in Adapted the. EMS are processed by Event Manager 210. Event 

Block 220 also creates an element-independent network Manager 210 correlates events received from user interface 

management message "ProcessEvent," using CORBA, applications (not depicted) and Adapter Blocks 220-229, 

including appropriate information, such as the identity of and synchronizes this constantly changing list with regis- 

Network Element 220, the type of the alarm, and probable 55 tered client applications. 

cause information. Adapter Block 220 then transmits that In a preferred embodiment, Event Manager 210 also 

element-independent message, via CORBA Backbone 215, provides alarm correlation (i.e., certain sets of alarms will 

to Event Manager 210. In a preferred embodiment, unsolic- invoke other alarms), alarm translation, alarm filtering, 

ited messages are generally routed from the Adapter Blocks e-mail user notifications and external alarm feeds for other 

220-229, directly to Event Manager 210 where the mes- 60 third-party network management systems (typically through 

sages (in the form of element-independent messages) are EMS-NMS interface 207). In addition to receiving fault and 

then distributed to other EMS applications such as Log alarm data, Event Manager 210 also processes performance 

Manager 213 and Upstream Agent 212. data and forwards the performance data to the appropriate 

As is apparent to one of skill in the art, the mapping of log manager, depicted in FIG. 2 as Log Manager 213, for 

other upstream element-dependent network management 65 insertion into an EMS Log 214. 

messages into corresponding upstream element-independent In a preferred embodiment, Event Manager 210 receives 

network management messages (and the mapping of down- three types of messages from Adapter Blocks 220-229: 
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unsolicited messages, twenty -four hour performance data, 
and eight -hour performance data (i.e., thirty-two sets of 
fifteen-minute performance data). An unsolicited message is 
generated, for example, when an alarm or other similar event 
has occurred on network Elements 230-239. In a preferred 
embodiment, Log Manager Server 213 maps data as 
received, from Adapter Blocks 230-239 through Event 
Manager 210, into pre-defined schema objects in the EMS 
Log 214. 

FIG. 3 depicts, in a preferred embodiment of an EMS 
according to the present invention, the logical relationship 
between network management messages in the core set of 
network management messages. In the preferred embodi- 
ment depicted in FIG. 3, Module EMS Common 301 pro- 
vides data-type definitions for core network management 
messages common to all applications within the EMS, 
including Module EMS Interface 310, Module Event Man- 
ager 320 and Module Log Manager 321. Module EMS 
Interface 310, which provides the core network management 
messages common to all NEs in the EMS, inherits (utilizes) 
the data-type definitions defined in Module EMS Common 
301. So, for example, if Module EMS Common 301 defines 
the data type for NEName as a "string," Module EMS 
Interface 310 can utilize the NEName string type. Module 
Event Manager 320 and Module Log Manager 321 are 
specific applications that utilize data-type definitions from 
EMSCommon. In a preferred embodiment, other applica- 
tions (not shown in FIG. 3) such as a request broker and an 
EMS agent, are implemented similarly. 

In the preferred embodiment depicted in FIG. 3, Module 
Radio 311 and Module MUX 312 provide the core set of 
type-specific network management messages for digital 
microwave radios and fiber optic devices, respectively. In 
this embodiment, each of Module Radio 311 and Module 
MUX 312 inherits the type definitions defined in Module 
EMS Interface 310. NE-speciflc interfaces, depicted in FIG. 
3 as Module 2000S 313, Module IMT-150 314 and Module 
FLM-150 315 contain type definitions for core network 
management messages for specific NEs. In the preferred 
embodiment depicted in FIG. 3, Module 2000S 313 inherits 
type definitions from Module Radio 311; and Module IMT- 
150 314 and Module FLM-150 315 inherit type definitions 
from Module MUX 312. In a preferred embodiment, addi- 
tional NE-specific modules are implemented similarly. 

FIG. 4 depicts network management message flows in a 
preferred embodiment of an EMS of the present invention. 
It should be noted that each of the message flows depicted 
in FIG. 4 is a logical message flow, and may be 
implemented, as is known in the art, using a physical or 
electronic path different from the logical message path. As 
depicted in FIG. 4, a preferred embodiment of an EMS 
includes EMS Applications 501, NMS (Network Manage- 
ment System) Applications 505, and EMS Domain 510. 
EMS Applications 501 includes Fault Performance Appli- 
cations module 503 and Configuration Applications module 
502. NMS Applications 505 includes NMS -EMS Interface 
506 and other NMS Applications 507. 

In the preferred embodiment depicted in FIG. 4, EMS 
Domain 510 includes Event Manager 511, Request Broker 
512, Upstream Agent 513, Log Manager 514, EMS Log 515, 
and EMS Platform 516. EMS Platform 516, in turn, includes 
CORBA Backbone 517 and Adapter Blocks 520, 521, 522 
and 523. As is apparent to one of skill in the art, adapter 
blocks may be added or removed from the embodiment 
depicted in FIG. 4. 

The functions and structures of each of the applications, 
modules, domains, platforms, managers, agents, blocks and 
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other elements depicted in FIG. 4 are described with refer- 
ence to FIG. 2 or 3, above, or are apparent to one of skill in 
the art in light of those descriptions. Each of those functions 
may be implemented in hardware or software, or a combi- 
S nation of hardware and software, and in various structures as 
known to one of skill in the art 

In the preferred embodiment depicted in FIG. 4, 
NE-independent network management messages are trans- 
mitted: 

1° from Event Manager 511 to Fault/Performance Applica- 
tions 503; 

from Event Manager 511 to Upstream Agent 513; 
from Event Manager 511 to Log Manager 514; 
15 from Request Broker 512 to Configuration Applications 

module 502, and from Configuration Applications 

module 502 to Request Broker 512; 
from Request Broker 512 to Upstream Agent 513, and 

from Upstream Agent 513 to Request Broker 512; 
2° from Upstream Agent 513 to NMS-EMS Interface 506, 

and from NMS-EMS Interface 506 to Upstream Agent 

513; and 

from Log Manager 514 to EMS Log 515; 
M from Request Broker 512 via CORBABackbone 517 (the 
NE-independent messages transmitted between these 
two modules include NE-independent request mes- 
sages and NE-independent messages in response to 
those request messages); 
30 via CORBA Backbone 517 to Event Manager 511 
(including unsolicited NE-independent alarm 
messages); and 
via CORBA Backbone 517 to and from each of Adapter 
Blocks 520-523. 
35 In the preferred embodiment depicted in FIG. 4, 
NE-dependent network management messages flow in each 
direction between each of Adapter Blocks 520, 521, 522 and 
523 and the specific Network Element 530, 531, 532 or 533 
served by the respective Adapter Block. 
40 The composition of NE-independent and NE-dependent 
network management messages, and the mapping between 
NE-independent and NE-dependent network management 
messages are described in detail with reference to FIGS. 1, 
2 and 3, above. 

45 In an example of another preferred embodiment of an 
EMS according to the present invention, depicted in FIG. 5, 
multiple EMSs may be distributed geographically to manage 
separate networks or network segments as needed. In the 
example shown in FIG. 5, Networks 601, 602, 603 and 604 

50 are coupled to each other by means of Ethernets 610, 620, 
630 and 643, Routers 650, 651, 653 and 654, and Frame 
Relay network 652. In Network 601, the EMS is distributed 
among two structures, EMS Server Components 611 and 
EMS Server Adapter Blks 612. In a preferred embodiment, 

55 EMS Server Components 611 contains basic EMS compo- 
nents described in detail above, such as an Event Manager, 
a Log Manager, a Request Broker, and an Upstream Agent 
(not depicted). The other structure in Network 601, depicted 
as EMS Server Adapter Blks 612, contains all of the adapter 

60 blocks serving Network Elements 613. The function and 
operation of adapter blocks is described in detail with 
reference to FIGS. 2 and 4. In the preferred embodiment 
depicted in FIG. 5, user application, such as an accounting 
program, may reside in yet another structure, depicted in 

65 FIG. 5 as EMS User Applications 614. In the EMS embodi- 
ment illustrated by Network 601, the EMS behaves as it 
would if all components were deployed in a single structure. 
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In the networks depicted in FIG. 5 as Networks 602 and 
603, all EMS Server Components are deployed on a single 
structure, illustrated in FIG, 5 by EMS Servers 622 and 631 
for each of Network 602 and Network 603, respectively. The 
EMS User Applications 621 and 632 may be deployed on 5 
one or more separate workstations, and those may be avail- 
able over Ethernets 620 and 630, for each of Networks 602 
and 603. 

In the preferred embodiment depicted in FIG. 5, Network 
604 supports a network management center for Networks 
601, 602 and 603. EMS User applications 642 support NE 
management functions for each of Networks 601, 602 and 
603, thus enabling centralized management of the NEs in 
each of those networks. NMS Server 644 and NMS User 
Applications 641 support network management functions at 
the TMN Network Layer, providing enhanced management 15 
capabilities at a higher level, as known to one of skill in the 
art. 

The connection of separate networks through Frame 
Relay 652 illustrates one embodiment of the present inven- 
tion. In alternative embodiments, the links between separate 20 
networks may be established through other telecommunica- 
tions networks and devices, as known to one of skill in the 
art. 

As more networks or network segments are added, addi- 
tional EMSs may be deployed as needed without impacting 25 
performance of any existing EMSs. If a single EMS must 
manage a large number of NEs, then the EMS itself may be 
distributed over several machines. 

The present invention has been disclosed and described 
herein in what is considered to be its most preferred embodi- 3Q 
ments. It should be noted that variations and equivalents 
may occur to those skilled in the art upon reading the present 
disclosure and that such variations and equivalents are 
intended to come within the scope of the invention and the 
appended claims. 

We claim: 

1. An element management system for a telecommunica- 
tions network, comprising 

means for receiving, from a software application, a down- 
stream element-independent network management 40 
message selected from a core set of downstream 
element- independent network management messages, 
for transmission to a telecommunications network 
element, wherein the core set of downstream element- 
independent network management messages comprises 45 
a reduced number of downstream network management 
messages supporting basic telecommunications net- 
work management functionality, and, wherein, with 
respect to at least one telecommunications network 
element in the telecommunications network, basic tele- 50 
communications network functionality comprises core 
common network management functions and core 
equipment type-specific network management func- 
tions; 

means for mapping the downstream element-independent 55 
network management message into a downstream 
element-dependent network management message, and 
into an element-dependent protocol, for the telecom- 
munications network element; and 

means for transmitting the downstream element- eo 
dependent network management message to the tele- 
communications network element. 

2. An element management system for a telecommunica- 
tions network, comprising 

means for receiving an upstream element-dependent net- 65 
work management message from a telecommunications 
network element; 
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means for mapping the upstream element-dependent net- 
work management message into an upstream element- 
independent network management message selected 
from a core set of upstream element-independent net- 
work management messages, and into a common 
element-independent message protocol, wherein the 
core set of upstream element -independent network 
management messages comprises a reduced number of 
upstream network management messages supporting 
basic telecommunications network management 
functionality, and, with respect to at least one telecom- 
munications network element in the telecommunica- 
tions network, basic telecommunications network func- 
tionality comprises core common network management 
functions and core equipment type-specific network 
management functions; and 

means for transmitting the upstream element -independent 
network management message to a software applica- 
tion. 

3. An element management system according to claim 2, 
wherein at least one message of the core set of upstream 
element-independent network messages corresponds to a 
message of a core set of downstream element-independent 
network messages. 

4. An element management system according to claim 2, 
wherein at least one upstream element-dependent network 
management message responds to a downstream element- 
dependent network management message. 

5. An element management system according to claim 1 
or 2, further including means for forwarding application 
requests to a specified telecommunications network element. 

6. An element management system according to claim 1 
or 2, wherein the core common network management func- 
tions comprise the functions of: 

monitoring faults and alarms in the telecommunications 
network element; 

configuring the telecommunications network element; 

monitoring performance of the telecommunications net- 
work element; and 

monitoring security of the telecommunications network 
element. 

7. An element management system according to claim 1 
or 2, wherein the core common network management func- 
tions comprise the functions of: 

setting a time clock for the telecommunications network 
element; 

setting threshold values for the telecommunications net- 
work element; 

retrieving performance data for a specified time period for 
the telecommunications network element; 

updating the external output control on the telecommu- 
nications network element; 

sending a signal to the external output interface on the 
telecommunications network element; 

updating the external input control attributes on the tele- 
communications network element; 

retrieving the operational status of the telecommunica- 
tions network element; 

processing equipment information from the telecommu- 
nications network element; 

retrieving and updating protection status for the telecom- 
munications network element; and 

processing alarms. 

8. An element management system according to claim 1 
or 2, wherein the core equipment type-specific network 
management functions comprise: 
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core microwave radio network management functions; 
and 

core fiber optic device network management functions. 

9. An element management system according to claim 8, 
wherein the core microwave radio network management 5 
functions comprise the functions of: 

invoking and releasing protection status for the telecom- 
munications network element; and 

requesting a manual exercise on a protection unit related 1Q 
to a regular channel used by the telecommunications 
network element. 

10. An element management system according to claim 8, 
wherein the core fiber optic device network management 
functions comprise the functions of: J5 

retrieving, entering, editing and removing a facility of a 

fiber optic device; and 
retrieving, performing and removing a cross-connection 

of a fiber optic device. 

11. An element management system according to claim 1 20 
or 2, further comprising means for processing fault man- 
agement information. 

12. An element management system according to claim 1 
or 2, further comprising means for logging network notifi- 
cations and events into a database. 25 

13. An element management system according to claim 1 
or 2, further comprising means for forwarding e-mail from 
a network management software application. 

14. An element management system according to claim 1 

or 2, further comprising means for communicating with a 30 
network management software application. 

15. An element management system according to claim 1 
or 2, further comprising means for storing notifications and 
events concerning the telecommunications network element. 

16. An element management system according to claim 1 35 
or 2, wherein the telecommunications network includes 
telecommunications network elements of more than one 
type. 

17. An element management system according to claim 1 

or 2, wherein the telecommunications network includes 40 
telecommunications network elements of more than one 
manufacturer. 

18. An element management system according to claim 1 
or 2, wherein the telecommunications network element is 
selected from a group consisting of a microwave radio and 45 
a fiber optic device. 

19. An element management system for a telecommuni- 
cations network, the element management system compris- 
ing: 

at least one adapter block, wherein each adapter block 50 
receives a plurality of upstream element-dependent 
network management messages from at least one 
network element served by the adapter block; 
maps each upstream element-dependent network man- 
agement message into one of a plurality of upstream 55 
element-independent network management mes- 
sages; 

sends upstream element-independent network manage- 
ment messages to a communications backbone; 

receives a plurality of downstream element- 60 
independent network management messages, from 
the communications backbone, for at least one net- 
work element served by the adapter block; 
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maps each downstream element-independent network 
management message into a downstream element- 
dependent network management message; and 

sends downstream element-dependent network man- 
agement messages to at least one network element 
served by the adapter block; 
wherein the communications backbone 

receives downstream element -independent network 
management messages, from a network management 
request broker, for transmission to at least one net- 
work element served by the adapter block; and 

sends upstream element-independent network manage- 
ment messages from the adapter block to the request 
broker; and 

wherein the request broker communicates with network 
management applications. 

20. The element system of claim 19, wherein the com- 
munications backbone sends upstream element-independent 
network management messages from the adapter block to an 
event manager in communications with network manage- 
ment applications. 

21. An adapter block for an element management system 
for a telecornmunications network, the adapter block com- 
prising: 

an upstream receiver for receiving a plurality of upstream 
element-dependent network management messages 
from at least one network element served by the adapter 
block; 

a downstream transmitter for sending a plurality of down- 
stream element-dependent network management mes- 
sages to the network element; 

an upstream transmitter for sending a plurality of 
upstream element-independent network management 
messages to a communications backbone in communi- 
cations with the adapter block; 

a downstream receiver for receiving a plurality of down- 
stream element-dependent network management mes- 
sages from the communications backbone; and 

processing means for mapping each upstream element- 
dependent network management message into one of 
the plurality of upstream element-independent network 
management messages, and for mapping each down- 
stream element-independent network management 
message into one of the plurality of downstream 
element-dependent network management messages. 

22. The adapter block of claim 21, wherein the commu- 
nications backbone 

receives downstream element-independent network man- 
agement messages, from a network management 
request broker, for transmission to at least one network 
element served by the adapter block; and 

sends element-independent network management mes- 
sages from the adapter block to the request broker. 

23. The adapter block of claim 22, wherein the request 
broker communicates with network management applica- 
tions. 

24. The adapter block of claim 23, wherein the commu- 
nications backbone sends upstream element-independent 
network management messages from the adapter block to an 
event manager in communication with network management 
applications. 

***** 
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